A runtime environment is a virtual machine state which provides software services for processes or programs while a computer is running. A runtime library is a collection of utility functions which support a program while it is running by working with the operating system. The Java Virtual Machine (JVM) (Java is a trademark of Sun Microsystems, Inc.) is an example of a runtime. The .NET framework is another example of a runtime.
The OSGi (Open Services Gateway initiative) modularity framework provides a dynamic component model for JVM environments. Applications or components in the form of bundles for deployment can be remotely managed and management of Java packages/classes is specified in detail. For example, the Eclipse platform (Eclipse is a trade mark of the Eclipse Foundation) is an open-source, platform independent software framework including the OSGi bundling framework.
The OSGi modularity framework provides the ability to define classes and resources (for example, configuration files) that are private to a particular application. It also allows an application to explicitly declare its dependence on other applications, frameworks or libraries. The net effect is that some classes are invisible to an application.
Aspect-oriented programming (AOP) aids programmers in the separation of concerns to improve modularity. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems. AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these “crosscutting concerns”. An aspect is treated as a class by OSGi in terms of visibility. A mechanism is required by AspectJ to determine which types in the system are aspects. The meta-data associated with the aspects must be visible to applications, except where an aspect is known to be private.
The load-time weaving (LTW) feature of AspectJ requires that the set of all aspects to be used to weave classes defined by a particular class loader are declared before any weaving takes place. This set must remain unchanged for the lifetime of the class loader. This emulates the process of weaving the set of classes that comprise an application during an earlier build process prior to execution.
An aspect configuration file is typically created during the compilation process and declares the aspects. In a runtime system, a complete set of all aspects visible to a class loader can be obtained without prior knowledge of the hierarchy topology.
A problem is that an aspect configuration file associated with a particular bundle is visible to every other bundle in the same runtime regardless of whether the aspects it declares are also visible (i.e. exported or imported). This causes a failure during LTW initialization that is indistinguishable from a user configuration error which may cause an application to behave incorrectly or fail.
One approach used by the AJEER project (AJEER is a trade mark of Open Source Technology Group) which provides AspectJ load-time aspect weaving (http://sourceforge.net/projects/ajeer/) is to register all aspects with the runtime and ensure they are all visible. However, this can have unexpected side affects on bundles if the scope of an aspect is incorrect. Also, in a moderately sized system (for example, the Eclipse platform) centrally published aspects are known to have an unacceptable affect on start-up performance.
Another approach would be to use one aspect configuration file for every exported package. That way a bundle could enumerate the set of visible bundles and attempt to load the corresponding configuration file. Unfortunately, the set of packages that is visible to a bundle cannot always be determined and a possibly large set of aspect configuration files would be difficult to maintain.
The problem described above is given in the context of aspects in the OSGi framework. However, the solution provided of aspect scoping may be applied to other modularity runtimes.